System and method for providing reconfigurable workflows

ABSTRACT

Methods, non-transitory computer-readable media and apparatuses for modifying a task flow are disclosed. For example, a method receives a request to modify the task flow template which is associated with a plurality of task flow modification rules. The method determines whether the request violates a modification rule of the plurality of task flow modification rules. A first rule specifies that no automated tasks in the task flow template can be deleted and a second rule specifies that no automated task in the task flow template can be moved to precede another automated task on which it depends. The method rejects the request when the request is determined to violate one of the first rule and the second rule of the plurality of task flow modification rules. Otherwise, the method modifies the task flow template in accordance with the request to produce a modified task flow template.

The present disclosure relates generally to task flows, or workflows,and more specifically, to managing modifications to such task flows.

BACKGROUND

Network provisioning in the mobility space has more churn in terms ofdesign and equipment versus standard telecommunication networks. Thereis constantly new equipment coming out which changes the way that workis performed. It is difficult to support such projects using standardbusiness process workflows because it takes significant developmentefforts and is costly to continually fund new projects to keep up withcurrent research, new tools and technology in the mobility space. Thus,a process workflow for mobility networks needs to be flexible and needsto be made quickly. However, current workflow creation tools may beinadequate to match the pace of development. In particular, traditionalBusiness Process Execution Language (BPEL) based workflows are powerfultools for automating business processes and are designed specificallyfor orchestration. However, alterations to BPEL-based workflowstypically require redeployment of the code, i.e., by workers withprogramming skills, in order to make any changes. One solution involvesdeveloping a workflow from scratch in a primary programming language,e.g., entirely in Java. This allows configurability by modifyingmetadata in a database.

SUMMARY

In one embodiment, the present disclosure provides a method formodifying a task flow template. For example, the method receives arequest to modify the task flow template which is associated with aplurality of task flow modification rules. The method determines whetherthe request violates a modification rule of the plurality of task flowmodification rules. A first rule specifies that no automated tasks inthe task flow template can be deleted and a second rule specifies thatno automated task in the task flow template can be moved to precedeanother automated task on which it depends. The method rejects therequest when the request is determined to violate one of the first ruleand the second rule of the plurality of task flow modification rules.The method modifies the task flow template in accordance with therequest to produce a modified task flow template, when the request isnot determined to violate one of the first rule and the second rule ofthe plurality of task flow modification rules. The method then displaysthe modified task flow template.

In another embodiment, the present disclosure provides a non-transitorycomputer-readable medium that stores instructions which when executed bya processor, cause the processor to perform operations for modifying atask flow template. The operations include: receiving a request tomodify the task flow template which is associated with a plurality oftask flow modification rules and determining whether the requestviolates a modification rule of the plurality of task flow modificationrules. A first rule specifies that no automated tasks in the task flowtemplate can be deleted and a second rule specifies that no automatedtask in the task flow template can be moved to precede another automatedtask on which it depends. The operations further include: rejecting therequest when the request is determined to violate one of the first ruleand the second rule of the plurality of task flow modification rules,modifying the task flow template in accordance with the request toproduce a modified task flow template, when the request is notdetermined to violate one of the first rule and the second rule of theplurality of task flow modification rules, and displaying the modifiedtask flow template.

In still another embodiment, the present disclosure provides a methodfor modifying a task flow instance. For example, the method receives arequest to modify the task flow instance which is associated with aplurality of task flow modification rules. The method determines whetherthe request violates a modification rule of the plurality of task flowmodification rules. A first rule specifies that no automated tasks inthe task flow instance can be deleted and a second rule specifies thatno automated task in the task flow instance can be moved to precedeanother automated task on which it depends. The method rejects therequest when the request is determined to violate one of the first ruleand the second rule of the plurality of task flow modification rules.The method modifies the task flow instance in accordance with therequest to produce a modified task flow instance, when the request isnot determined to violate one of the first rule and the second rule ofthe plurality of task flow modification rules. The method then displaysthe modified task flow instance.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure can be readily understood by considering thefollowing detailed description in conjunction with the accompanyingdrawings, in which:

FIG. 1 illustrates one example of a communication network of the presentdisclosure;

FIG. 2 illustrates an example of creating a task flow instance from atask flow template for a work order;

FIG. 3 illustrates an example flowchart of a method for modifying a taskflow; and

FIG. 4 illustrates a high-level block diagram of a general-purposecomputer suitable for use in performing the functions described herein.

To facilitate understanding, identical reference numerals have beenused, where possible, to designate identical elements that are common tothe figures.

DETAILED DESCRIPTION

The present disclosure broadly discloses methods, non-transitory (i.e.,tangible or physical) computer readable media, and apparatuses forcreating, editing, modifying and observing workflows, or task flows,which include a combination of automated and manual tasks. Embodimentsof the present disclosure provide users with the ability to predict andsee the future of the task flow as it progresses and the ability of auser to modify the task flow, but in a constrained way, such that theuser does not break the system and is limited to only “safe” portions ofthe task flow. In particular, embodiments of the present disclosureprovide a highly flexible, modular workflow engine that allows for rapidturnaround of minor changes to the flow. By coupling a collection ofautomated processes implemented in Business Process Execution Language(BPEL) with a task flow templating engine and driver implemented in Java(or any language capable of web services and database connectivity)backed by a rules engine for decision-making, the task flow may bemodified by simply updating tables in a database. The main task flowitself is completely dynamic. Thus, the code deployed to the system doesnot need to change, and minor changes to the system can be activatedimmediately by business personnel, e.g., users without computerprogramming skills. In contrast, alterations to BPEL-based workflowstypically require redeployment of the code, i.e., by users withprogramming skills, in order to make any changes. In addition, intraditional BPEL-based workflows, there is no convenient means todisplay to end users what steps in the task flow will be performed next.Embodiments of the present disclosure provide the flexibility ofconfiguring a task flow entirely in the database with the robustness ofBPEL-based task flows for allowing users to better anticipate staffingneeds as the task flow progresses, to more accurately answer questionsabout when certain tasks will take place, and so forth.

The following terms are used herein:

Work Order—a plan or request for an activity or specific outcome, whichwill require a number of tasks to be completed in order to reach thespecific outcome. For example, a request may be to deploy a new celltower in a network. A number of tasks to reach this outcome may include:generating a site survey, requesting and receiving permits from variousstate and federal agencies, ordering of equipment, transportingequipment to the location, laying a foundation, erecting the tower,connecting to the backhaul, adjusting the sectors, testing signalstrength, and so forth. The work order may include data relating to therequest, such as a location or set of locations, a budget, a number ofavailable personnel to devote, a start date, a desired end date, and soforth.

Task Flow/Work Flow—a task flow, or a work flow, comprises anarrangement of tasks/steps to be performed in order to reach the goaland/or produce the result requested in the work order. A task flow mayinclude not only the tasks to be performed, but the order in which thetasks follow from one another, i.e., the task dependencies andconditional rules relating to the tasks and/or the entire task flow. Invarious embodiments, the tasks in a task flow may include both automatedtasks and manual tasks. In addition, some tasks may comprise a“sub-flow” having a sequence of tasks to be performed. A task flow isoften represented graphically in a flow chart where different tasks arerepresented by boxes and directional arrows between tasks show whichtasks precede and which task follow from one another.

Task Flow Template—a preexisting task flow archetype designed for aparticular activity type. In one example, the present disclosure assumesthat a task flow template will exist for the specific activity requestedin the work order.

Task Flow Instance—a task flow created by copying the task flow templatefor a particular activity type when a work order relating to theparticular activity type is created or received. The task flow instancemay, but need not be modified from the task flow template to tailor thetask flow, e.g., based upon data relating to the work order, such as alocation where the requested activity will take place, a budget, anumber of available personnel to devote to the requested activity, astart date, a desired end date, and so forth.

To aid in understanding the present disclosure, FIG. 1 illustrates ablock diagram depicting one example of a communication network 100suitable for performing or enabling the steps, functions, operationsand/or features described herein. The overall communication network 100may include any number of interconnected networks which may use the sameor different communication technologies, such as a traditional circuitswitched network (e.g., a public switched telephone network (PSTN)) or apacket network such as an Internet Protocol (IP) network (e.g., an IPMultimedia Subsystem (IMS) network), an asynchronous transfer mode (ATM)network, a wireless network, a cellular network (e.g., 2G, 3G, and thelike), a long term evolution (LTE) network, and so forth. It should benoted that an IP network is broadly defined as a network that usesInternet Protocol to exchange data packets.

As shown in FIG. 1, the system 100 connects a user device 160 with oneor more application servers via a core network 110, access networks 120and 122, private network 130 and/or Internet 180. In one embodiment,core network 110, e.g., an IP network, interfaces with one or more ofthe access networks 120 and 122, and may also include interfaces to theInternet 180 and/or private network 130. Access network 120 may comprisea wireless access network (e.g., an IEEE 802.11/Wi-Fi network and thelike) or a cellular access network, and may include a cellular basestation and/or wireless access point 145. In one embodiment, accessnetwork 122 may comprise a PSTN access network, a cable access network,a wired access network and the like. In one embodiment, the accessnetworks 120 and 122 and the core network 110 may be operated bydifferent service providers, the same service provider or a combinationthereof. In embodiment, the core network 110 may be operated by acommunication network service provider. In addition, private network 130may comprise a corporate intranet, a network of an educationalinstitution, a home network, and the like. For example, user device 160may provide local or remote access for a corporate employee, a student,etc., to private network 130, either directly or through one or moreintermediate networks. Various interconnections between access networks120 and 122, core network 110, Internet 180 and private network 130 areshown. In accordance with the present disclosure, it is contemplatedthat devices may utilize any one or a combination of such networks andinterfaces in order to communicate with one another.

In one embodiment, the core network 110 may include an applicationserver (AS) 115 and a database (DB) 116. Although only a single AS 115and a single DB 116 are illustrated, it should be noted that any numberof application servers 115 or databases 116 may be deployed. In oneembodiment, the AS 115 may comprise a general purpose computer asillustrated in FIG. 4 and discussed below. In one embodiment, the AS 115hosts a program for creating, editing, viewing and managing task flowsin accordance with the present disclosure. As such, DB 116 may storeprogram code, data, files, and so forth in connection with such aprogram. Similarly, private network 130 may include an applicationserver (AS) 125 and a database (DB) 126, which may be the same orsimilar to AS 115 and DB 116 in the core network 110.

In one embodiment, user device 160 may comprise any endpoint deviceconfigured for wireless or wired communication such as a personalcomputer, a laptop computer, a Personal Digital Assistant (PDA), amobile phone, a smart phone, an email device, a tablet, a messagingdevice, and the like. In one embodiment, user device 160 provides accessto a user to either or both of the application servers 115 and 125 tocreate, modify and access task flows in accordance with the presentdisclosure.

It should be noted that the network 100 has been simplified. Forexample, the network 100 may include other network elements (not shown)such as border elements, routers, switches, policy servers, securitydevices, gateways, a content distribution network (CDN) and the like.Thus, FIG. 1 is only intended to illustrate one exemplary environment inwhich embodiments of the present disclosure may be employed. Inaddition, although FIG. 1 illustrates a user device 160 for accessingapplication servers 115 and 125, in a different embodiment, the presentdisclosure may be implemented via a console integrated with AS 115and/or 125, or may even comprise a stand-alone device. For instance, inone example, computing device 400 in FIG. 4 may comprise such astandalone device which may host and store a program and related datafor creating, editing, viewing and managing task flows in accordancewith the present disclosure.

To further aid in understanding, FIG. 2 illustrates an example of thecreation and progression of a task flow instance, i.e., a task flow. Asmentioned above, in one example the present disclosure assumes that atask flow template exists for a particular requested activity of a workorder. For example, an employee of a mobile network provider may submita work order for the deployment of a new cell tower in Monmouth County,N.J. Accordingly, in one example it is assumed that a work flow templateexists for this type of activity. As shown in FIG. 2 the deployment of anew cell tower has previously been given work order type “J” which has atemplate 200.

In one example, templates are created by a designer, or a developmentteam, and made available to users who need to implement task flows tofulfill various work orders. To illustrate, a first task flow templatemay be created by a development team for the deployment of new celltowers. Another task flow template may be created by the same or adifferent development team for upgrades to a backhaul to support fourthgeneration (4G) technology. Note that the present disclosure is notlimited to work orders and task flows related to mobility networks or totelecommunication network in general. Rather, embodiments of the presentdisclosure are broadly applicable to all categories of task flows whichsupport complex business processes. In any case, when a work order isreceived, the work order type is determined and an appropriate task flowtemplate is retrieved. For instance, if the work order is for deployinga new cell tower, the task flow template for deploying a new cell toweris retrieved.

In the example of FIG. 2, task flow template 200 is retrieved, whichincludes a set of tasks that comprise the work flow and an indication asto whether each task is a manual task or an automated task. In additionto the set of tasks, the task flow template 200 may include or isassociated with a set of conditional rules 210, comprising e.g.: (1)visibility/inclusion rules—for determining whether and under whatconditions each task in the task flow template 200 should be included ina specific instance of the task flow, (2) duration rules—for determiningthe anticipated duration of the task, (3) routing rules—primarily fordetermining which work group(s) will perform manual tasks, and (4) taskflow rules—for restricting or constraining modifications to the taskflow in general and/or to particular tasks or subsets of tasks. Theserules or parameters are created by the designer/development team whencreating a task flow template 200. In one example, the rules may belinked to the task flow template, stored in a data structure along withthe task flow template, or may comprise a library or database of ruleswhich are retrieved by a task flow program and applied to a the taskflow template. An ability to modify the task flow template, and any taskflow instances derived from the template, is provided to all users, butis constrained within these rules, as described in greater detail below.

As an example of a visibility rule, task flow template 200 includes thetasks “ABC-PREF” (ABC preferred) and “ABC-ALT” (ABC alternative).Depending upon input data as part of the work order, either one, but notboth of these tasks may be performed. For example, a conditional rulemay specify that when the work order is for an activity to take place inthe northeastern United States, that ABC-PREF should not be included ina specific instance of the task flow. Similarly, another conditionalrule may specify that ABC-ALT should be performed when the work order isindicated to be an activity to be performed in the northeastern UnitedStates. Task flow instance 220 shows the outcome of this evaluationprocess over the task flow template for a specific work order. Forexample, as described above the work order may request the deployment ofa new cell tower. In addition, the work order includes accompanyinginput data such as the location, e.g., Monmouth County, N.J., themaximum budget, the desired start date, the number of personnel todevote to the project, and so forth. Thus, using this input data, theconditional rules can be evaluated to determine that ABC-PREF should beexcluded, while ABC-ALT should be included. Accordingly, as illustratedin FIG. 2, the task flow instance 220 created from the task flowtemplate 210 for this specific work order includes only ABC-ALT, whereasABC-PREF is omitted.

The following illustrates the use of conditional rules relating to taskduration, or “durational rules.” In particular, as shown in task flowinstance 220, the first task “WOVAL” (which may stand for “work ordervalidation”) is an automated task which has an anticipated completiontime of T+1, where T=0 may comprise an arbitrary start time. Incrementsmay be business days, business hours, or any other measure of time. Forillustrative purposes, the increments are considered to be businessdays. Thus, it is anticipated that the automated task WOVAL will becompleted 1 business day after the commencement. On the other hand, thenext task “PRE-RRD” is a manual task and is anticipated to be completed20 business days after the start of the project.

In order to make predictions about when future tasks will commence andbe completed, in one embodiment all of the conditional rules relating totask duration for a sequence of tasks in the task flow arepre-evaluated. Notably, other approaches, such as current deployments ofBusiness Process Execution Language (BPEL), only evaluate conditionalrules, e.g., IF conditions, when the IF conditions are encountered asthe work flow progresses. In contrast, embodiments of the presentdisclosure advantageously provide a future view of the task flow,enhancing the ability for those involved in the project to plan andanticipate future developments. For example, each task may include anumber of durational rules, such as IF conditions, that may contributeto a prediction of the time it takes to complete the task. One exampleis: IF number_of_personnel={10-15} THEN time_to_complete=10; IFnumber_of_personnel={15-25} THEN time_to_complete=5. Another example is:IF location=Minnesota and date={December, January, February} THENtime_to_complete=March 1+15. To illustrate, the particular task maycomprise pouring a concrete foundation, which is best not performedduring cold months. Accordingly, the task may only have a 15 businessday anticipated duration, but according to the development team thatcreated the task flow template 200, the task should not be commenceduntil at least March 1, regardless of the completion status of anyprevious tasks. In another example, one task may have a duration of twobusiness days if the work order relates to the eastern United States, orthree business days if the work order relates to the western UnitedStates, or it may be two or three business days depending upon the typeof vendor. These are only several examples and should not be interpretedas limitations on the present disclosure. Thus, there can be variousconditions which determine the anticipated duration of a task.

In one example, conditional rules relating to duration are onlypre-evaluated up to an interim point of confidence, beyond which thedesigner considers the predictions are not useful or reliable. Forexample, as the beginning tasks are completed, more data may becomeavailable that is required to evaluate the estimated times forcompletion of future tasks. Before these initial tasks are completed,any estimates about the latter tasks may be uncertain. The time tocomplete latter tasks, and whether certain latter tasks will even beperformed in the particular flow may be dependent upon the outcome of anearlier task. For instance, the future of the task flow may be dependentupon the sub-soil structure that is found in an earlier site-evaluationtask. It may take a longer time and require more material and manpowerto establish a site foundation for a base station where there is a highwater table and silt versus a dry spot with compacted clay. In anotherexample, the task flow instance 220 may include multiple branches wherea decision task may select which branch to eventually follow. Forexample, if a site survey determines that the ground of the site has anincline of greater than 30 degrees, the task flow instance 220 mayinclude a branch or subset of tasks that needs to be performed, whereasif the ground is substantially level, that particular branch of the taskflow instance need not be performed. However, the designer and theuser(s) implementing the task flow may not have the ability to predictwhether this condition is fulfilled until the project commences.

As also shown in FIG. 2, in the task flow instance 220 the third task is“PLAN”, which represents a planning point. Only the first two tasks upto the planning point have been pre-evaluated and include completiontime estimates. In a different embodiment, the present disclosure maypre-evaluate all conditional rules relating to duration for all tasks ina task flow instance, but may include signals to indicate predictionswhich are not reliable. For example, a visual representation of the taskflow instance may display washed out or grayed completion timepredictions for tasks which are deep into the task flow.

Task flow instance 230 shows the same task flow instance 220 at a latertime, e.g., after the first planning point has been reached. Notably,the times for the first two tasks, as well as for the third task (theplanning point) are the actual completion times. In one example, theplanning point itself comprises an automated task that is part of thetask flow. Its purpose is to evaluate the durational rules/conditionsrelating to the next sequence of task following the planning point up toa next planning point, or up to the end of the task flow. As shown, task“RRD” is a manual task that is in progress with an anticipatedcompletion time of T+35 (35 business days after the commencement of theproject). The next tasks “XYZ” and “ABC-ALT” are automated and manualtasks respectively having the anticipated completion times shown in thefigure.

As mentioned above, the task flow template 200 may also include globaltask flow modification rules which restrict the customizability of thetask flow template and any task flow instances created form the taskflow template. In addition, the task flow template 200 may include morelocalized task flow modification rules which restrict modifications thatmay be made to certain portions of the task flow, e.g., to a subset oftasks which are grouped together, to a specific task, and the like.Notably, a user may have various legitimate reasons to need to modify atask flow. For example, a user may need to account for a previouslyunplanned site inspection, an audit, damage caused by a weather event,and so forth. However, the designer may wish to limit the ability ofusers to modify a task flow such that the users are guaranteed to notbreak the task flow. In accordance with the present disclosure, sometask flow modification rules are so ubiquitous that the rules areapplicable by default to all task flows, e.g., “universal” task flowmodification rules. Examples of universal or global task flowmodification rules include: a rule that no automated tasks in the taskflow can be deleted, and a rule that a new task cannot be insertedbefore an automated task in the task flow that depends upon a precedingautomated task. Other rules of this nature include: a rule that a manualtask may be inserted into the task flow, a rule that an automated taskcannot be inserted into the task flow, a rule that an approved automatedtask can be inserted into the task flow and a non-approved automatedtask cannot be inserted into the task flow, a rule that a manual taskcannot be inserted between two automated tasks in the task flow whichhaving a rule (e.g., a local rule) that specifies the two automatedtasks cannot be separated, a rule that a task cannot be deleted from thetask flow unless the task is a manual task that has previously beeninserted into the task flow, and a rule that a task cannot be insertedbetween two tasks in a sequence of tasks where one of the tasks in thesequence is currently being performed (e.g., where a local rule of thetask flow is associated with the sequence of tasks and specifies thatthe sequence of tasks cannot be interrupted). In another example, auniversal rule may comprise a rule that the durational rule of a task ischangeable for manual tasks and is not changeable for automated tasks.In one example, an approved automated task is available from a paletteof automated tasks designated by the designer as safe to include in thetask flow. For example, an automated scan of configuration settings orother read-related tasks may always be safe to insert in a task flow.For instance, no matter how many times a read task is performed, it willnot have a measurable impact upon any other automated tasks.

Note that the foregoing are only several examples that are provided forillustrative purposes. In addition, some of the foregoing examples aremutually exclusive. Thus, different embodiments of a task flow template(and task flow instances derived therefrom) may have different sets oftask flow modification rules applicable thereto. It should also be notedthat two of the above examples describe “global” task flow modificationrules which, in order to evaluate, require the existence and knowledgeof “local” task flow modification rules. For instance, in order todetermine whether a modification to a task flow requesting the insertionof a manual task violates the rule that “a manual task cannot beinserted between two automated tasks in the task flow having a rule thatspecifies the two automated tasks cannot be separated,” there must be arule applicable to two of the automated tasks that indicates the twotasks are linked in an unbreakable sequence and cannot be separated.Thus, the existence of this local rule enables the evaluation of the“global rule.” Of course, if there are no local rules linking any twoautomated tasks together in an unbreakable chain, or if the user isseeking to insert a new task between automated tasks that are notlinked, then this global rule is not applicable. In any case, in variousexamples the global task flow modification rules interact with localmodification rules to provide a decision as to whether to accept orreject a request to modify the task flow instance.

As a further example of local rules, one or more rules may specifycertain automated tasks before or after which a manual task cannot beinserted by the user, regardless of whether it is followed by anautomated or a manual task. In another example, a local rule may specifythat two adjacent tasks can be separated by the inclusion of a new task,but for no more than a particular duration of time, e.g., a task can beinserted so long as the anticipated duration of the task does not exceed5 business days, 10 business days, etc. In still another example, thedesigner may include positive local rules such as specifying that aparticular automated task can have a manual task follow it, regardlessof whether another automated task follows it in the original task flowtemplate. Similarly, in one example certain manual tasks included in thetask flow template and instantiated in a task flow instance may beconsidered to be optional tasks. Thus, for example, if the designerindicates that a manual task is optional, in one embodiment a local rulemay specify that this particular manual task may be deleted by a userfrom the task flow instance, notwithstanding the fact that the task wasincluded in the original task flow instance created from the task flowtemplate. In another example, a manual task in the task flow may have arule that specifies whether or not a visibility/inclusion rule can beadded to the task, or whether such a visibility/inclusion rule can bemodified, if already present. In still another example, certain manualtasks may be tagged with rules that indicate whether or not the manualtask can be moved. For instance, certain manual tasks may have noparticularly important order of performance with respect to one another,e.g., signal testing of a new base station can proceed while painting ofcertain components and landscaping is planted to screen the site. On theother hand, some tasks may have a specific required order ofperformance, e.g., to deploy a new cell tower, a concrete foundationmust be poured before the mast can be erected. As such, local rulesassociated with one or more of the tasks may grant appropriatepermissions and place appropriate constraints on users to be able torearrange/not rearrange the task flow. In one example, such local rulesallow rearrangement of certain groups of tasks in relation to oneanother while ensuring that certain tasks that must be performedtogether and/or sequentially, remain in the particular order. Forexample, the order of performance of two blocks of tasks may be swapped,while the tasks within each block remain in the same order with respectto one another. In one example, any manual task that is inserted in thetask flow has a default maximum time duration. Thus, a user cannotinsert a manual task with a non-specific anticipated time duration or aduration that exceeds the default, e.g., 5 business days, 20 businessdays, and so forth. Other limitations of this nature may be imposed onthe tasks inserted by a user to maintain the integrity of the task flow.Thus, the inclusion of local and global task flow modification rules inthe task flow template guarantees that users who seek to modify taskflow instances created from such templates are able to customize thetask flow, but are constrained in such a way that these users cannotbreak the task flow and only affect “safe” portions of the task flow.

In addition, where a task flow instance is modified in compliance withsuch rules, the estimated completion dates of subsequent tasks in thetask flow may be re-evaluated. For example, the pre-evaluation of theconditional rules relating to duration for subsequent tasks may beevaluated again in order to account for the time estimated for theinclusion of a new task, the deletion of a task, or the rearrangement ofone or more tasks. In one embodiment, all durational rules for tasksthat follow from an inserted or deleted task up to a next plan point orto the end of the task flow are re-evaluated.

Although not illustrated in FIG. 2, embodiments of the presentdisclosure may employ a work order engine for receiving a work order,for orchestrating the actual implementation of a task flow, forinterfacing with users and/or for displaying task flows and task flowprogress for such users. For example, the work flow engine may beimplemented in one of the application servers 115 or 125, or in userdevice 160 in FIG. 1, or may be implemented as a computing device, suchas computing device 400 in FIG. 4 described below.

In one embodiment, the work order engine has two primary components, atask execution main flow, and a task allocation flow. In one example,the purpose of the task execution main flow is to send instructions andcall the appropriate work centers, personnel or automated resources toperform various tasks, and to accounting for the completion of theassigned tasks. For example, the task execution main flow may instruct adevice, server, or even a component of the same system/device on whichit resides to perform the first automated task “WOVAL” in the task flowinstance 220. In one embodiment, the task execution main flow sendsautomated tasks to an automated task handler to actually assign-out theautomated task. The task execution main flow may also assign manual taskto appropriate work centers. For example, as mentioned above, tasks in atask flow may have routing rules which specific work center(s) to whichthe task should be assigned. In one embodiment, the task execution mainflow passes the manual task to a manual task handler for furtherprocessing and to make the actual task assignment to a work center. Inone example, the task execution main flow and/or manual task handlerprovides a dialog box or other user interface to an appropriate user,e.g., a manager, to indicate that a particular manual task is ready tobe worked and to provide an opportunity for the user to indicate thecompletion of the manual task, e.g., by sending a reply message back tothe manual task handler and/or task execution main flow.

In one embodiment, the purpose of the task allocation flow is toretrieve upcoming tasks in the task flow for processing by the taskexecution main flow. For example, the task execution main flow maycommand the task allocation flow to retrieve a next task, or set of nexttasks from the task flow, so long as there are additional tasksavailable. In one embodiment, the task allocation flow is responsiblefor evaluating conditional visibility rules of the tasks in the taskflow. Thus, in one example, the task execution main flow requests andreceives from the task allocation flow only a portion of tasks in a taskflow up to a next planning point. Accordingly, the view of the task flowinstance provided to a user by the work order engine may only includetasks up to a next planning point. After a planning point is reached,the task allocation flow may then retrieve the next sequence of tasks upto a subsequent planning point (or to the end of the task flow),evaluate conditional visibility rules, and only pass those tasks whichare evaluated to be included in the task flow instance to the taskexecution main flow.

To further aid in understanding the present disclosure, FIG. 3illustrates an example flowchart of one embodiment of a method 300 formodifying a task flow in accordance with the present disclosure. In oneembodiment, the steps, functions, or operations of the method 300 may beperformed by the user device 160, an application server such as AS 115or 125, or a general purpose computer or computing device as describedin FIG. 4 and discussed below.

The method 300 begins at step 302 and proceeds to optional step 310. Atoptional step 310, the method 300 receives a work order and accompanyingdata relating to an activity. For example, as described above the workorder may be for the deployment of a new cell tower and may include datarelating to the request, such as a location, a budget, a number ofavailable personnel to devote, a start date, a desired end date, and soforth. For example, the accompanying data may indicate that the requestis for deployment of the new cell tower in Monmouth County, N.J., 50personnel are to be devoted to the project, the anticipated peak numberof calls serviced by the cell tower is 1000 per hour, the desired startdate is Jun. 1, 2013, and so forth.

At optional step 320, the method 300 retrieves a task flow templatecorresponding to the particular activity. For example, as describedabove a designer or development team may create a task flow template fora particular activity. Notably, the activity may be a complex businessprocess which needs to be performed many times. Thus, a reusable taskflow template may be created by experienced users. When a work order forthe particular activity type is received, the method thus retrieves theappropriate task flow template, e.g., from a plurality of available taskflow templates for various different activity types. As mentioned above,the task flow template may include a sequence of various tasks as wellas conditional rules relating to visibility, duration, routing and/ortask flow modification.

At optional step 330, the method 300 creates a task flow, or a “taskflow instance,” from the task flow template. In one embodiment, step 330comprises evaluating conditional rules relating to visibility of aplurality of tasks. In one embodiment, the evaluation of the conditionalrules is based upon the accompany data received with the work order atstep 310. For instance, as shown in FIG. 2, task flow template 200includes the tasks “ABC-PREF” (ABC preferred) and “ABC-ALT” (ABCalternative). Depending upon input data as part of the work order,either one, but not both of these tasks may be performed. For example, aconditional visibility rule may specify that when the work order is foran activity to take place in the northeastern United States, thatABC-PREF should not be included in a specific instance of the task flow.Similarly, another conditional visibility rule may specify that ABC-ALTshould be performed when the work order is indicated to be an activityto be performed in the northeastern United States. Task flow instance220 shows the outcome of this evaluation process over the task flowtemplate for a specific work order. In any case, the task flow createdat step 330 includes a plurality of tasks, relations and/or dependenciesbetween the task, e.g., the order in which the tasks are to beperformed, and conditional rules relating to duration, routing and/ortask flow modification. The task flow may also include some or all ofthe input data received along with the work order at step 310.

In one embodiment, the task flow created at step 330 may include or isassociated with one or more task flow modification rules that providepermissions and/or constraints on the ability of users to later modifythe task flow. For example, the task flow created at step 330 mayinherit the task flow modification rules from the task flow templatefrom which it was created. In one example, the task flow modificationrules are included in the task flow template by the template designer.In another example, the task flow modification rules are universal ruleswhich are applicable across an organization to all task flow templatesand all task flow created from such templates.

At step 340, the method 300 receives a request to modify the task flow.In various examples, the request may be to insert a new task in the taskflow, to delete an existing task from, the task flow, or torearrange/move tasks within the task flow. For example, a user may needto account for an unplanned site visit, an audit or an unexpectedweather event. Similarly, a user may be instructed to provide an interimreport on the status of the work order. Thus, the user may need toinsert one or more tasks into the task flow to take inventory of variousaspect of the project. Similarly, the user may be instructed to speed upthe project and to reduce the scope of the project in order to meet thenew deadline. Thus, the user may need to delete one or more tasks as aresult.

At step 350, the method 300 determines whether the request violates amodification rule of the one or more task flow modification rules. Forexample, as mentioned above the task flow may include task flowmodification rules in addition to the tasks, task dependencies and otherdata. The task flow modification rules may include both local and globalrules. The task flow modification rules evaluated at step 350 may alsoinclude universal task flow modification rules which are applicable toall task flows across an organization. In one embodiment, the task flowmodification rules, whether they be universal, global or local, mayinclude: a rule that no automated tasks in the task flow can be deleted,and a rule that a new task cannot be inserted before an automated taskin the task flow that depends upon a preceding automated task. The rulesmay also include: a rule that a manual task may be inserted into thetask flow, a rule that an automated task cannot be inserted into thetask flow, a rule that an approved automated task can be inserted intothe task flow and a non-approved automated task cannot be inserted intothe task flow, a rule that a manual task cannot be inserted between twoautomated tasks in the task flow when a local rule that specifies thetwo automated tasks cannot be separated, a rule that specifies a taskcannot be deleted from the task flow unless the task is a manual taskthat has previously been inserted into the task flow, a rule thatspecifies a task cannot be inserted between two tasks in a sequence oftasks where one of the tasks in the series of tasks is currently beingperformed, e.g., where a local rule of the task flow is associated withthe sequence of tasks and specifies that the sequence of tasks cannot beinterrupted, a rule that permits a deletion of a manual task when themanual task has been marked in the task flow template as beingnon-essential, a rule that permits the movement/relocation of a group oftasks (but only as a block), and so forth.

If, at step 350, the method 300 determines that the request violates atask flow modification rule, the method proceeds to step 360. At step360, the method 300 rejects the request. In one example, a message maybe provided to a user to indicate that the request has been denied.However, in another example the user may be provided a warning, but isallowed to make the modification after explicitly disregarding warning.

If, at step 350, the method 300 determines that the request does notviolate any one of the task flow modification rules (e.g., where no ruleis applicable, or where a rule specifically permits the modification),the method proceeds to step 370. At step 370, the method 300 modifiesthe task flow to fulfill the request. For example, the method may inserta task, delete a task, rearrange or move a task or block of tasks, andso forth, depending upon the particular type of request that wasreceived at step 340. The result of step 370 is a modified task flow.

Following either of steps 360 and 370, the method 300 proceeds to step380. At step 380, the method 300 displays the task flow, or the taskflow that has been modified. In one example, the display of the taskflow includes a view of the completion status of each task in the taskflow and anticipated completion times for all or a portion of the tasksin the task flow that have yet to be performed. For example, the taskflow may be displayed as a list, e.g., as shown in FIG. 2. In oneexample, step 380 comprises re-evaluating various conditional rules forone or more task in the task flow up to a next planning point or to anend of the task flow. For instance, step 380 may include re-evaluatingconditional rules, and more specifically the durational rules associatedwith each task from a point or task in the task flow relating to themodification request, e.g., from the point where a new task is insertedor a task is deleted, up to the next planning point (or to the end ofthe task flow). The re-evaluation for each subsequent task may accountfor the anticipated duration of a task that has been inserted into thetask flow, a task that has been deleted from the task flow, and soforth.

Following step 380, the method proceeds to step 395 where the methodends.

It should be noted that although steps 340-380 of the method 300 havebeen described in connection with modifications to a task flow instance,the present disclosure is also applicable to modifications to the taskflow itself. Thus, in one example steps 340-380 may be similarly appliedto handling requests to modify the task flow template. In particular, atleast a portion of the rules that may be invoked at step 250 withrespect to modifications to a task flow instance may be equally appliedto requests to modify the task flow template. In other words, the taskflow template, in one embodiment may be considered a “master copy” of atask flow, or a task flow instance and may be modified, subject to thesame rules/restrictions described above.

In addition, it should be noted that although not explicitly specified,one or more steps, operations or blocks of the method 300 describedabove may include a storing, displaying and/or outputting step asrequired for a particular application. In other words, any data,records, fields, and/or intermediate results discussed in the methodscan be stored, displayed, and/or outputted to another device as requiredfor a particular application. Furthermore, steps, operations or blocksin FIG. 3 that recite a determining operation, or involve a decision, donot necessarily require that both branches of the determining operationbe practiced. In other words, one of the branches of the determiningoperation can be deemed as an optional step. Furthermore, operations,steps or blocks of the above described method can be combined,separated, and/or performed in a different order from that describedabove, without departing from the example embodiments of the presentdisclosure.

FIG. 4 depicts a high-level block diagram of a general-purpose computeror system suitable for use in performing the functions described herein.For example, any one or more components or devices illustrated in FIG. 1or described in connection with the method 300 may be implemented as thesystem 400. As depicted in FIG. 4, the system 400 comprises a hardwareprocessor element 402 (e.g., a microprocessor, a central processing unit(CPU) and the like), a memory 404, (e.g., random access memory (RAM),read only memory (ROM), a disk drive, an optical drive, a magneticdrive, and/or a Universal Serial Bus (USB) drive), a module 405 formodifying a task flow, and various input/output devices 406, e.g., acamera, a video camera, storage devices, including but not limited to, atape drive, a floppy drive, a hard disk drive or a compact disk drive, areceiver, a transmitter, a speaker, a display, a speech synthesizer, anoutput port, and a user input device (such as a keyboard, a keypad, amouse, and the like).

It should be noted that the present disclosure can be implemented insoftware and/or in a combination of software and hardware, e.g., usingapplication specific integrated circuits (ASIC), a general purposecomputer or any other hardware equivalents, e.g., computer readableinstructions pertaining to the method(s) discussed above can be used toconfigure a hardware processor to perform the steps functions and/oroperations of the above disclosed methods. In one embodiment, thepresent module or process 405 for modifying a task flow can beimplemented as computer-executable instructions (e.g., a softwareprogram comprising computer-executable instructions) and loaded intomemory 404 and executed by hardware processor 402 to implement thefunctions as discussed above. As such, the present module or process 405for modifying a task flow as discussed above in method 300 (includingassociated data structures) of the present disclosure can be stored on anon-transitory (e.g., tangible or physical) computer readable storagemedium, e.g., RAM memory, magnetic or optical drive or diskette and thelike.

It should be noted that the hardware processor can be configured orprogrammed to cause other devices to perform one or more operations asdiscussed above. In other words, the hardware processor may serve thefunction of a central controller directing other devices to perform theone or more operations as discussed above.

While various embodiments have been described above, it should beunderstood that they have been presented by way of example only, and notlimitation. Thus, the breadth and scope of a preferred embodiment shouldnot be limited by any of the above-described exemplary embodiments, butshould be defined only in accordance with the following claims and theirequivalents.

What is claimed is:
 1. A method for modifying a task flow template,comprising: receiving, by a processor, a request to modify the task flowtemplate, wherein the task flow template is associated with a pluralityof task flow modification rules; determining, by the processor, whetherthe request violates a modification rule of the plurality of task flowmodification rules, wherein a first rule of the plurality of task flowmodification rules specifies that no automated tasks in the task flowtemplate can be deleted, wherein a second rule of the plurality of taskflow modification rules specifies that no automated task in the taskflow instance can be moved to precede another automated task on which itdepends; rejecting the request, by the processor, when the request isdetermined to violate one of the first rule and the second rule of theplurality of task flow modification rules; modifying, by the processor,the task flow template in accordance with the request to produce amodified task flow template, when the request is not determined toviolate one of the first rule and the second rule of the plurality oftask flow modification rules; and displaying, by the processor, themodified task flow template when the task flow is modified in accordancewith the request.
 2. The method of claim 1, wherein a third rule of theplurality of task flow modification rules specifies that an approvedautomated task can be inserted into the task flow and a non-approvedautomated task cannot be inserted into the task flow.
 3. The method ofclaim 1, wherein a third rule of the plurality of task flow modificationrules specifies that a manual task cannot be inserted between twoautomated tasks in the task flow having a rule that specifies the twoautomated tasks cannot be separated.
 4. The method of claim 1, wherein athird rule of the plurality of task flow modification rules specifiesthat two adjacent tasks cannot be separated by more than a specifiedtime duration when inserting a new task.
 5. The method of claim 1,wherein a third rule of the plurality of task flow modification rulesspecifies whether a manual task is moveable.
 6. The method of claim 1,wherein each of a plurality of tasks in the task flow has an associateddurational rule, wherein the durational rule is changeable for tasks ofthe plurality of tasks.
 7. The method of claim 1, wherein a task in thetask flow has a rule that specifies that an inclusion rule of the taskis changeable for manual tasks and is not changeable for automatedtasks, wherein the inclusion rule is for determining conditions underwhich the task is included in a task flow instance derived from the taskflow template.
 8. A non-transitory computer-readable medium storinginstructions which, when executed by a processor, cause the processor toperform operations for modifying a task flow template, the operationscomprising: receiving a request to modify the task flow template,wherein the task flow template is associated with a plurality of taskflow modification rules; determining whether the request violates amodification rule of the plurality of task flow modification rules,wherein a first rule of the plurality of task flow modification rulesspecifies that no automated tasks in the task flow template can bedeleted, wherein a second rule of the plurality of task flowmodification rules specifies that no automated task in the task flowinstance can be moved to precede another automated task on which itdepends; rejecting the request when the request is determined to violateone of the first rule and the second rule of the plurality of task flowmodification rules; modifying the task flow template in accordance withthe request to produce a modified task flow template, when the requestis not determined to violate one of the first rule and the second ruleof the plurality of task flow modification rules; and displaying themodified task flow template.
 9. A method for modifying a task flowinstance, comprising: receiving, by a processor, a request to modify thetask flow instances, wherein the task flow instance is associated with aplurality of task flow modification rules; determining, by theprocessor, whether the request violates a modification rule of theplurality of task flow modification rules, wherein a first rule of theplurality of task flow modification rules specifies that no automatedtasks in the task flow instance can be deleted, wherein a second rule ofthe plurality of task flow modification rules specifies that noautomated task in the task flow instance can be moved to precede anotherautomated task on which it depends; rejecting the request, by theprocessor, when the request is determined to violate one of the firstrule and the second rule of the plurality of task flow modificationrules; modifying, by the processor, the task flow instance in accordancewith the request to produce a modified task flow instance, when therequest is not determined to violate one of the first rule and thesecond rule of the plurality of task flow modification rules; anddisplaying, by the processor, the modified task flow instance when thetask flow is modified in accordance with the request.
 10. The method ofclaim 9, wherein a third rule of the plurality of task flow modificationrules specifies that a task cannot be inserted between two tasks in asequence of tasks where one of the tasks in the series of tasks iscurrently being performed, wherein a rule of the task flow template isassociated with the sequence of tasks and specifies that the sequence oftasks cannot be interrupted.
 11. The method of claim 9, furthercomprising: receiving a work order and accompanying data relating to anactivity; and retrieving a task flow template, wherein the task flowtemplate corresponds to the activity.
 12. The method of claim 11,further comprising: creating the task flow instance from the task flowtemplate based upon the data relating to the activity.
 13. The method ofclaim 12, wherein the creating the task flow instance from the task flowtemplate comprises evaluating conditional rules of the task flowtemplate to select tasks from the task flow template to include in thetask flow instance.
 14. The method of claim 11, wherein the accompanyingdata comprises: a location where the activity is to take place.
 15. Themethod of claim 11, wherein the accompanying data comprises: a number ofavailable personnel to perform manual tasks.
 16. The method of claim 11,wherein the accompanying data comprises: a budget for the activity. 17.The method of claim 9, wherein the displaying comprises: presenting aview of the modified task flow instance which includes: a listing oftasks in the modified task flow instance; a completion status of each ofthe tasks; and a time when each of the tasks that is not completed isanticipated to be completed.
 18. The method of claim 17, wherein eachtask in the modified task flow has an associated durational rule,wherein the time when each task that is not completed is anticipated tobe completed is calculated based upon a pre-evaluation of the associateddurational rule.
 19. The method of claim 9, wherein the displayingcomprises: re-evaluating a conditional rule of each of a plurality ofuncompleted task in the modified task flow; and updating a view of thetask flow to include a revised anticipated completion time of each ofthe plurality of uncompleted tasks in the modified task flow up to thenext planning point.
 20. The method of claim 19, wherein each of theplurality of uncompleted tasks comprises a task in the modified taskflow between a task that is the subject of the request and a nextplanning point.